Subject: New Multicast Proposal

From: David Bryant/HQ/3Com <[email-masked]>
Date: 25 Jun 96 19:17:45 EDT

Just sent out a revised copy of the Multicast proposal.  I've encorporated all 
the changes we discussed at the last AIW.  I had to restructure the document a 
bit in order to cover everything, so there's some significant changes.  I 
suggest rereading the entire document.

I've put it out on the net in the best format I could find to accomodate the 
various translation gateways.  I hope it arrives in a readable format.  The 
original text was Courier font.   I'll also try to get the original word 
document placed out on the FTP server tomorrow.   This version will have 
revision bars in it as well. 

I suggest everyone read through it before the AIW and post comments to this 
mail exploder.    This way we'll have a much more productive meeting in NC next 
month.

Cheers, Dave

---

From: Frank Bordonaro <[email-masked]>
Date: Fri, 12 Jul 1996 15:07:18 -0400 (EDT)

> mail exploder.    This way we'll have a much more productive meeting in NC next 

Dave,

I have a strong concern regarding the references to using unicast in 
place of a multicast mechanism in the current proposal. In my opinion,
there are too many contractdictions in the current proposal regarding
when it is acceptable/recomended to send via UDP unicast.

The current multicast proposal contains a section entitle
"Unicast and UDP Datagrams in Lieu of IP Multicast". This section states
that "it is possible for implementations to simply make use of the UDP
transport mechanism described in this paper without making direct use of
the IP multicast function".

This is exactly the type of flexibilty that is behind my push for the addition
of unicast-only support, but this section is not enough. The current multicast 
proposal contains "shoulds" and "musts" throughout that discourage/prohibit use
of unicasting when multicast "should/must" be used. 

In my opinion, we need to be more flexible and allow implementations 
to send any frame via UDP unicast.  There are too many ways an 
implementation can optimze traffic flow if it had this flexibility. For
example, there are cases when a CanUReach_Ex/NAME_QUERY_ex should only be 
sent to a subset of DLSw peer nodes for optimal scalability. This behavior 
should be allowed and encouraged. As it reads in the NetBIOS section of the
proposal, the table and note 2 in particular states that NAME_QUERY_ex
"should always be multicast on the WAN".

I am not sure how to interpret these contradictions. Are we trying to 
encorporate the support for sending of any  frame via UDP unicast?

It seems to me we have 2 choices.

1) Clean up contradictions in the current proposal to explicity allow
   the sending of any packet UDP unicast. In this case, the unicast 
   proposal can go away.

2) Clean up contradictions in the current proposal to explicity disallow
   the sending of certain packets UDP unicast. If this route is chosen, I 
   would like to see the Unicast proposal I posted on April 11 be integrated
   as a sub-chapter in the DLSw Version 2 Scalability Document.

Before reading the current proposal, I thought we were going with option 2,
but since the current multicast proposal tosses around the use of unicast
in lieu of multicast, it may be easier for us as a group to work on one
proposal and make it satisfy all requirements.

Regards,
Frank Bordonaro
cisco Systems, Inc.